home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20020314-20021006 / 000002_fdc@columbia.edu_Thu Mar 14 13:31:47 EST 2002.msg < prev    next >
Text File  |  2002-10-06  |  5KB  |  101 lines

  1. Article: 13267 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: Experience with K95 over satellite links
  6. Date: 14 Mar 2002 13:31:02 -0500
  7. Organization: Columbia University
  8. Lines: 84
  9. Message-ID: <a6qq96$efo$1@watsol.cc.columbia.edu>
  10. References: <c4914b87.0203140931.41ac24bc@posting.google.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1016130663 10236 128.59.39.139 (14 Mar 2002 18:31:03 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 14 Mar 2002 18:31:03 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13267
  16.  
  17. In article <c4914b87.0203140931.41ac24bc@posting.google.com>,
  18. satprof <satprof@altavista.com> wrote:
  19. : Following my posting at the end of Jan, 2002 about evaluating Kermit
  20. : for a project to transfer ~70MB of data nightly via a double(!)
  21. : satellite hop, it might be useful for others in the future to hear of
  22. : my experiences.
  23. : ...
  24. : The approach I adopted was to set up the K95D.EXE 'daemon' on the
  25. : machine holding the data & to script the file transfer on the machine
  26. : to which the data was to be sent. Before leaving for Africa, I tested
  27. : the script (based on the 'reliable file transfer' script in the K95
  28. : 'scripts' folder) between my home in France & my office in Geneva.
  29. : With an ADSL link at home (& T3 at the office) my tests showed around
  30. : 20KB/second. (Ping time ~ 40mSec)
  31. : However, on arrival in Africa, I couldn't achieve more than about
  32. : 3KB/second in practice. The receiving end showed only that a single
  33. : window was in use, but that is apparently normal at the receiver.
  34. :
  35. Right.  The reciever's window size goes up only when a packet is missing.
  36. When the missing packet eventually shows up, it can write out its window
  37. to disk and the window size goes back to one.
  38.  
  39. : The
  40. : sending end showed that sliding windows were in use, but only 5 out of
  41. : 30 possible. (Packet size settled down to 4000/3999; streaming was off
  42. : to ensure block checking & the Fast macro was invoked.)
  43. :
  44. That means the sender was receiving acknowledgements within five packet
  45. times.  The window never grows larger than it needs to, and the sender
  46. is pushing out packets as fast as it can.  My guess is that your modem
  47. was flow-controlling the PC, which would happen if the PAD was
  48. flow-controlling the answering modem, which is not a stretch.  Remember,
  49. the PAD is taking each 4K packet and segmenting it into 32 128-byte
  50. packets and sending them over an X.25 network with a window size of 7,
  51. using go-back-to-n retransmission strategy rather than selective repeat
  52. like Kermit.  If the satellite links are dirty or lossy, this can result
  53. in awful (but still presumably error-free) end-to-end throughput.
  54.  
  55. If you use hardware flow control, the modem lights would tell the tale.
  56.  
  57. If you weren't using modems at all, the same principals would still apply.
  58.  
  59. : The relatively slow speed was a bit of a disappointment, but it was
  60. : overcome by initiating 5 concurrent instances of Kermit, and
  61. : transferring the data in parts.
  62. :
  63. That's just the right thing to do in a situation like this.  Each
  64. connection is its own virtual circuit within the X.25 cloud and so does
  65. not affect the others.
  66.  
  67. : The prime reason for the post is to record this for others, but I'd
  68. : also like to thank Frank & the others in the group for their input at
  69. : the beginning of the project.
  70. Our pleasure :-)
  71.  
  72. : If anyone has any ideas about how to increase the no. of windows
  73. : actually used, I'd like to try that out.
  74. :
  75. See above.  Modern Kermits have a default maximum window size of 30, and
  76. they use all the slots they need to use at any given moment.  If the
  77. number of slots used is low and your throughput is also low, it means
  78. Kermit is being throttled by the communication medium.
  79.  
  80. If the Kermit-to-Kermit connection was over TCP/IP as I assume it must
  81. have been since K95D.EXE is involved, you might have done better to
  82. simply allow streaming.  On the other hand you might also have done
  83. better by making a directly dialed connection so as not to have the
  84. differing transport strategies of Kermit, TCP/IP, and X.25 all fighting
  85. each other at once.
  86.  
  87. : I also tried to get K95D.EXE
  88. : to run as a WINNT service, but without success, so would be interested
  89. : to know if anyone has managed this elsewhere.
  90. This is quite straightforward in the new release, which is in its
  91. final days of Beta testing:
  92.  
  93.   http://www.columbia.edu/kermit/k95next.html
  94.  
  95. Thanks for the terrific report -- I wish everybody would do that!
  96.  
  97. - Frank
  98.